This is a monthly segment in which Versant Object Technology reviews some aspect of object databases. This month's tip focuses on indexes.

INDEXES IN VERSANT

One of the great performance enhancements provided by the object database paradigm is the use of pointer navigation to move from object to object. This eliminates the need for joins and is often cited as one of the main reasons object databases can outperform their relational counterparts for complex data manipulation, as well as for object caching.

However, there are times when predicates are needed to query on root objects before beginning a navigation. Versant supports the full range of Boolean operations and path query capabilities on its selections. In order to make a query perform faster, one can place an index on the attributes used in where clauses.

There are two types of indexes in Versant. A hash table can be used for relatively small amounts of data in which equality will be the main operator for the query and most of the values of the target objects are unique for the index. For large amounts of data in which the whole host of relational operators will be used in the predicate, it is highly recommended to specify a B-Tree when creating the index. The B-Tree is the default access method for an index.

Once an index is created for an attribute, Versant automatically updates the index data structures when new objects are created which make use of the attribute, when objects which make use of the attribute are deleted, and when modifications are made to the indexed attribute. This sometimes leads to what can be called "programmer explosion of indexed attributes."

Because it is so easy to place an index on an attribute, some designers will simply place an index on every attribute of the class. Because indexes must be stored in their own pages and updated, this is generally not a good idea. Indexes should only be placed on attributes which will be involved in query predicates. In general, do not place an index on an attribute which has only an equally distributed Boolean cardinality. The purpose of an index is to gain access performance, not to incur unnecessary DBMS overhead.

In order to maximize useful network throughput, Versant performs its queries on the server. Only objects which match the query predicate are sent to the client cache, which could even be on the same machine or in the same process. Objects which do not match the query predicate are not then unnecessarily wasting network bandwidth.

Versant uses a query optimizer to determine which of several competing indexes to use. The general rule is that if a hash index can be used effectively (for equality), it will be. If no hash index can be used, then the leftmost B-tree index that can be used will be used.

As for pattern matching, if there is a B-tree index on the matched attribute that can be effectively used, (e.g., the name matches "Russ*"), then it will be used. Since index pages must also be in shared memory on the server when performing the query, be sure to set the Backend profile parameter max_page_buffs, to be large enough to hold the index pages as well as the objects. This will greatly enhance performance.

You can also use the Versant statistics utility to monitor the performance of your index with other useful parameters. Please consult the Versant System Manual for further information on Versant parameters.

by Nimish Doshi

[ What's New | Products | Partners | Tech Support | About Us | Employment | Contact Us | Search | Home ]
[ C++ Solutions | SmallTalk Solutions | Internet Solutions ]